Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9704/000034_owner-urn-ietf _Wed Apr 30 09:37:35 1997.msg

Internet Message Format | 1997-04-30 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id JAA19997
    for urn-ietf-out; Wed, 30 Apr 1997 09:37:35 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with ESMTP id JAA19992
    for <[e-mail]>; Wed, 30 Apr 1997 09:37:32 -0400 (EDT)
Received: from octave.collegeleboeuf.qc.ca ([e-mail] [204.19.108.3])
    by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id JAA01306
    for <[e-mail]>; Wed, 30 Apr 1997 09:37:29 -0400 (EDT)
Received: from dmartin.cedep (ppp16.collegeleboeuf.qc.ca [204.19.108.65]) by octave.collegeleboeuf.qc.ca (8.8.5/8.6.9) with ESMTP id JAA05760 for <[e-mail]>; Wed, 30 Apr 1997 09:23:22 -0400 (EDT)
Message-Id: <[e-mail]>
From: "didier ph martin" <[e-mail]>
To: "URN Workgroup" <[e-mail]>
Subject: [URN] About realtive URNs
Date: Wed, 30 Apr 1997 09:38:24 -0400
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: "didier ph martin" <[e-mail]>
Errors-To: [e-mail]

Hi,

I know that we are not there yet, I mean we don't have any RFC or Draft
about relative URNs. However, because of the nature of our work, we have to
had to create a relative URN schema.

We are currently working on the integration of indexing, meta data and
URNs. To say that in couple words. We set a language were a list of objects
are defined with attribute value pairs. Each object is uniquely refered
within the collection with a URN. The urn follow the actuals drafts and RFC
for urn syntax (i.e:  <URN> ::= "urn:" <NID> ":" <NSS>). Our NSS is a
hierarchical name space like one found in the Path NSS (as you now an other
URN). Our NID is TNS for Tranportable Name Space. At the minimum an object
is defined with to attibutes:
a) its URN and its URL.

Because of the nature of our NSS, it is possible to set relative paths from
a base URN. So in the Index definition file we set a base URN. All
subsequent objects are then defined with relative NSS from this base.
Example:

destination:"urn:tns:Desktop/MyNameSpace"
tocOf:"http://www.w3.org"
......
......
.....

unit:"name1"
location:"/specs"

In this example both URNs and URLs are relative. each unit or object is
relative to the destination URN (i.e name space) and each unit's location
is relative to tocOf URL.

Basically what this is doing is: A portion of a name space is transported
from one name space to an other. the destination attribute indicates the
pivot point or insertion point within the destination name space. All
subsequent objects defined after this header are relative to the base
insertion point. This scheme works for many hierarchical name spaces like
directories, shell desktop name spaces, etc...

So, after having stated our work, we are greatly interested in discution a
common scheme for relative URNs. This NSS can serve as a base for relative
URNs. My bet is that some name space will be good candidates for relative
URNs, this will be obviously hierarchical name spaces. Flat name spaces
will be harder to set as relative URNs except if they hide a hiearchical
structure like ISBN. Maybe a good start would be to take ISBN and TSN name
spaces as a base (I know we will have to define TSN as a URN scheme.
speaking of this, is there any template for this? Who's working on the
sample URN NSS draft or RFC? we can follow the same format).

My first suggestion is that we use the following rule that we can call the
concatenation rule:

The base URN is concatenated to each relative URN. So in the example above
we have:

Base URN = urn:tns:Desktop/My Name space
relative URN = name1

complete URN = Base + Relative = urn:tns:Desktop/My Name space + name1 =
urn:tns:Desktop/My Name space/name1

We can apply this concatenation principle to other NSS candidates for
relative URNs. Thus, the idea, is that is we have defined a base URN
(should be an absolute one) relative URN are based on this one. Name
resolution should be done first by concatenating the base (absolute) and
the relative URNs, this results with an absolute URN.

Comments? I saw part of the discussion about ISBN and a relative schema,
How could we set a ISBN relative URN without deforming the name space (NSS)
naming convention (I mean here hte xxx-xxx- naming system). Is the
concatenation rule making sense in other contexts than our. Are there any
showtopper for relative URNs?

I can just tell you that practically, it is a lot more economical to have
relative URNs (there is less to code, in the case of hierarchical name
spaces, you don't have to rewrite the whole hierarchy each time). This easy
to implement. An interpreter can easily be set to resolve urns with the
concatenation rule. And all this is not a simple theoritical exercice, we
have actually a concrete example of this with up to 50 000 downloads up and
running. This is probably the largest URN running implementation today.

Have a good day.

Didier PH Martin
[e-mail]
http://www.netfolder.com